10 research outputs found

    An ontological framework to manage the relative conflicts between security and usability requirements

    Full text link
    Non Functional Requirements (NFRs) are relative, so are the conflicts among them. In our previously developed catalogue of NFRs conflicts it can be observed that a number of specific pairs of NFRs are claimed to be in conflicts in some cases but they are also claimed not to be in conflict in the other cases. These relative conflicts occur because the positive or negative relationships among NFRs are not always clear and obvious. These relationships might change depending on the meaning of NFRs within the system being developed. This paper focuses on the application of ontology in managing the relative conflicts among NFRs, particularly the relative conflicts between security and usability requirements. The aim is to develop a framework to identify, characterize, and define corresponding resolution strategies for the security-usability conflicts. This paper thus describes the sureCM framework to manage these conflicts; summarizes the security-usability conflicts ontology; and demonstrates how the ontology will be used as a basis to assist analysts in managing conflicts between security and usability requirements. ©2010 IEEE

    Conflict characterization and Analysis of Non Functional Requirements: An experimental approach

    Full text link
    Prior studies reveal that conflicts among Non Functional Requirements (NFRs) are not always absolute. They can also be relative depending on the context of the system being developed. Given that existing techniques to manage the NFRs conflicts are mainly focused on cataloguing the interrelationships among various types of NFRs, hence a technique to manage the NFRs conflicts with respect to NFRs relative characteristic is needed. This paper presents a novel framework to manage the conflicts among NFRs with respect to NFRs relative characteristic. By applying an experimental approach, the quantitative evidence of NFRs conflicts will be obtained and modeled. NFRs metrics and measures will be used in the experiments as parameters to generate the quantitative evidence. This evidence can then allow developers to identify and reason about the NFRs conflicts. We also provide an example of how this framework could be applied. © 2013 IEEE

    An investigation into the notion of non-functional requirements

    Full text link
    Although Non-Functional Requirements (NFRs) are recognized as very important contributors to the success of software projects, studies to date indicate that there is still no general consensus in the software engineering community regarding the notion of NFRs. This paper presents the result of an extensive and systematic analysis of the extant literature over three NFRs dimensions: (1) definition and terminology; (2) types; and (3) relevant NFRs in various types of systems and application domains. Two different perspectives to consider NFRs are described. A comprehensive catalogue of NFRs types as well as the top five NFRs that are frequently considered are presented. This paper also offers a novel classification of NFRs based on types of systems and application domains. This classification could assist software developers in identifying which NFRs are important in a particular application domain and for specific systems. © 2010 ACM

    Managing conflicts among non-functional requirements

    Full text link
    Abstractâ Non-functional requirements (NFRs) tend to interfere, conflict, and contradict with one other. Unlike functional requirements, this inevitable conflict arises as a result of inherent contradiction among various types of NFRs. A number of techniques to deal with this conflict have been developed. Majority of them focus on categorizing, documenting, or listing the potential conflicts among NFRs. Several models that represent the positive or negative relationships among NFRs have also been published in literature. However, the interpretation of NFRs may vary depending on numerous factors, such as the context of the system being developed and stakeholder involvement. Consequently, the relationships among them are not always obvious. This paper investigates the gaps in the existing research literature about the conflicts among NFRs and proposes a framework to manage this type of conflict

    Constructing a Catalogue of Conflicts among Non-functional Requirements

    Full text link
    Non-Functional Requirements (NFRs) are recognized as a critical factor to the success of software projects because they address the essential issue of software quality. NFRs tend to interfere, conflict, and contradict with one another and this conflict is widely acknowledged as one of the key characteristics of NFRs. Several models of NFRs conflicts have been proposed and the interacting nature of NFRs has been characterized as either positive or negative inter-relationships among NFRs. Positive relationship represents a pair of NFRs that are supporting each other while negative relationship represents those NFRs that are conflicting with one another. Furthermore, as NFRs are also relative, the interpretation of NFRs may vary depending on many factors such as the context of the system being developed and the extent of stakeholders' involvement. The multiple interpretations of NFRs may lead to positive or negative inter-relationships that are not always obvious. These relationships may change depending on the meaning of NFRs in the system being developed. Hence, the existing potential conflicts models remain in disagreement with one other. This paper presents the result of an extensive and systematic investigation of the extant literature over the notion of NFRs and the conflicts among them. Rigorous synthesis of the carefully reviewed literature has resulted in the construction of a catalogue of NFRs conflicts with respect to NFRs relative characteristic. The relativity of conflicts is characterized by three categories: absolute conflict; relative conflict; and never conflict. This comprehensive catalogue could assist software developers with identifying the NFRs conflicts, performing conflicts analysis, and suggesting potential strategies to resolve these conflicts. © Springer-Verlag Berlin Heidelberg 2011

    Towards a catalogue of conflicts among non-functional requirements

    Full text link
    Two of the most significant characteristics of non-functional requirements (NFRs) are "interacting" and "relative". Interacting means NFRs tend to interfere, conflict, and contradict with one other while relative means the interpretation of NFRs may vary depending on many factors, such as the context of the system being developed and the extent of stakeholder involvement. For the purpose of understanding the interacting characteristic of NFRs, several potential conflict models have been presented in the literature. These models represent the positive or negative inter-relationships among various types of NFRs. However, none of them deal with the relative characteristic of NFRs. In fact, multiple interpretations of NFRs in the system being developed may lead to positive or negative inter-relationships that are not always obvious. As a result, the existing potential conflict models remain in disagreement with one other. This paper presents the result of an extensive and systematic investigation of the extant literature over the notion of NFRs and conflicts among them. A catalogue of NFRs conflicts with respect to the NFRs relative characteristic is presented. The relativity of conflicts is characterized by three categories: absolute conflict; relative conflict; and never conflict. This catalogue could assist software developers in identifying the conflicts among NFRs, performing further conflict analysis, and identifying the potential strategies to resolve those conflicts

    Utilizing TOPSIS: A Multi Criteria Decision Analysis Technique for Non-Functional Requirements Conflicts

    Full text link
    Experience shows that many software systems suffer from inherent conflict among Non-Functional Requirements (NFRs). It also confirms that resolution strategies for handling NFRs conflicts often result in changing overall design guidelines, not by simply changing one module. Therefore, in software system development, software developers need to analyse the NFRs and conflicts among them in order to make decisions about alternative design solutions. This paper presents the use of Multi Criteria Decision Analysis (MCDA) approach for NFRs conflict decision analysis. TOPSIS (Technique for Order of Preference by Similarity to Ideal Solution), as one of the essential MCDA techniques has been adopted to resolve such conflict. We show how the systematic application of TOPSIS can assist software developers select the most preferable design solutions with respect to the conflicting NFRs. The quantitative result generated with this technique will be used as the basis for decision support. An example that shows the application of TOPSIS is also presented. © Springer-Verlag Berlin Heidelberg 2014

    A comparison of software quality characteristics and software sustainability characteristics

    No full text
    Software sustainability has generated much interest in the software engineering field in recent times, and has been widely investigated across different fields and from different standpoints. The relationship between software quality and software sustainability is still an open question. In this study, a literature survey and comparison was conducted using three-phases, having as a starting point the comparison of basic models for software quality. A follow-up study, conducted at a more comprehensive level to cover both basic models and the most cited tailored models., Software sustainability literature is investigated to find the most frequent characteristics. Finally, data gathered from these studies and a comparison shows a similarity in the top level of these characteristics between software sustainability and software quality, and the emphasis on sustainability, maintainability and portability. The study suggests that ISO 25010 can be utilised by software sustainability. As a future work, the findings will be investigated empirically to support designing software sustainability framework identifying the most important criteria in the technical dimension.</div
    corecore